Repository navigation
feat(config): publish the config schemas as draft-07 under supabase.com/schemas - #7366
Conversation
…om/schemas (CLI-2856) The config, project-config and supabase.lock schemas now declare draft-07 and use $ids under https://supabase.com/schemas/<name>/v1.json. The committed copies move to apps/docs/public/schemas/ to mirror that layout, and a unit test fails on post-draft-07 keywords or drift from the source. readLock accepts locks that still carry the old $schema URL.
There was a problem hiding this comment.
🤖 AI Review
Verified all six input findings and merged the overlapping lock compatibility reports into one, yielding five confirmed findings. The main regression is that newly written or rewritten v1 locks are rejected by older CLIs. Legacy schema assets are also removed without compatibility routes. The remaining findings concern stale paths and duplicated generated definitions.
Findings
| Severity | Location | Category | Sources | Claim |
|---|---|---|---|---|
| 🟠 MAJOR | packages/stack/src/Lock.ts:12 |
backward-compatibility |
claude+codex | Changing the persisted $schema URL while retaining lockfileVersion 1 makes newly written and rewritten locks unreadable by earlier CLIs, breaking shared checkouts and CI pinned to those versions. |
| 🟡 MINOR | apps/docs/public/schemas/config/v1.json:3 |
backward-compatibility |
codex | Moving the published schema assets removes the legacy paths referenced by existing configuration documents and locks without providing compatibility assets or routes. |
| 🟡 MINOR | .gitattributes:31 |
stale-reference |
claude | The generated-file attributes still target deleted public/cli schema paths, leaving the replacement public/schemas files unmarked. |
| ⚪ NIT | apps/docs/public/schemas/supabase-lock/v1.json:305 |
schema-quality |
claude | The newly published lock schema contains eleven identical ServiceLock definitions with numbered names, repeating the resolved-pin structure and unnecessarily expanding the artifact. |
| ⚪ NIT | docs/self-documenting-cli.md:27 |
documentation |
claude | The generator documentation still places schema assets under public/cli/, although generation now writes public/schemas//v1.json. |
Findings outside the diff
- 🟡 MINOR
.gitattributes:31— The generated-file attributes still target deleted public/cli schema paths, leaving the replacement public/schemas files unmarked. - ⚪ NIT
docs/self-documenting-cli.md:27— The generator documentation still places schema assets under public/cli/, although generation now writes public/schemas//v1.json.
Stats
Claude findings: 4 · Codex findings: 2 · Confirmed: 5 · Refuted: 0 · Uncertain: 0
Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run
This review runs once per PR. A maintainer can request another with a /ai-review comment.
jgoux
left a comment
There was a problem hiding this comment.
Draft-07 conversion, the new paths and the drift test look right. The affected unit and integration tests pass, and all three committed schemas validate and compile as draft-07. Four small follow-ups are inline.
…2856) The published supabase.lock schema now lists the hosted URL alongside the legacy one in its $schema enum, matching what readLock accepts. The lock tests pin the historical literal, and the README and docs tree describe the draft-07 schemas under public/schemas/.
Summary
The config, project-config and
supabase.lockschemas declared draft 2020-12, and their$ids pointed atsupabase.com/docs/cli/..., which 404s. Taplo (Even Better TOML) doesn't support anything newer than draft-07, and the schemas only use keywords draft-07 already has. So this moves all three to draft-07, with$ids at the URLs they'll be hosted at.toPublishedJsonSchemaDocumentand the lock schema now go through Effect'sJsonSchema.toDocumentDraft07. That converter turns$defsintodefinitions, rewrites the refs, and throws on anything draft-07 can't represent rather than dropping it$ids move tohttps://supabase.com/schemas/{config,project-config,supabase-lock}/v1.json. Nothing is served there yet. CLI-2865 sets up the path in supabase/supabase and CLI-2864 publishes to it on stable releasesapps/docs/public/cli/*.schema.jsontoapps/docs/public/schemas/<name>/v1.json. That's the same layout as the hosted URLs, so the publisher can copy the folder across as-issupabase.lockkeeps being written with its original$schemavalue, because older CLIs check that field as a literal and would reject anything else. Reads also accept the hosted URL (HOSTED_LOCK_SCHEMA_URL), so a later release can switch writes over once enough CLIs read itapps/cli/scripts/published-schemas.unit.test.tsruns in the existing unit job. It fails when a committed schema:#/$defs/$idthat doesn't match its file pathLockschema. Regenerating it also brings in the current shape (noArtifactPin). The per-serviceServiceLockschemas render identically, so the published schema collapses them into one definitionSchema shape change
@supabase/config/schema.jsonand@supabase/config/project-schema.jsonnow declare draft-07 (http://json-schema.org/draft-07/schema#) and the new$ids.CLI_CONFIG_SCHEMA_URLandPROJECT_CONFIG_SCHEMA_URLchange value to match. The schema bodies are otherwise unchanged. If you validate them with a 2020-12-only validator such asAjv2020, switch to a draft-07 one.Code that uses those constants as a default
$schemanow writes the new URL. Existing$schemavalues in user config files aren't changed.Linked issue
Closes CLI-2856